Layout: a middle or bottom cell of a split row that goes on is lined up by the text it keeps (#6579) - #6580

Fixes #6579.

In a row that splits across pages, a cell aligned to the middle or bottom whose own text goes on to the next page started at the top of the cell on the first page. Word lines it up there by the text it keeps.

Baseline of each cell's first line, pt from the page top (Word for Windows 16.0.20625; the file is the one from #6579: a row cut after 17 lines of 11.5 pt, the first cell keeping all 17 on the first page, the centred and the bottom-aligned cell 15 each):

What changes, in crates/layout/src/table.rs:

• align_in_part also lines up the middle and bottom cells that go on. It already knew how far the text kept on the page reaches in every cell it does not line up whole (kept, the most of them); it now keeps each cell's own reach as well, and moves a cell that goes on down by the difference, half of it when centred. A cell that keeps as much as the tallest does not move, which is the case the code handled until now.
• The rest of the row is as tall as before. split_row_with measured it from the smallest distance any cell's text moves up for the next page; a cell lined up lower moves up that much further, so its lowering is taken off again (lowered). Without this the rest of the row came out shorter by the lowering whenever the lined-up cell had the most text left, and everything below it sat higher.
• layout_table records the alignment of every middle and bottom cell that is not turned (CellPart::align), where it recorded only the cells whose content had moved. A centred cell as tall as its row moves nowhere in the whole row and still has to be lined up in a part of it. For the whole row and for table_flow, which read the distance moved, a distance of zero changes nothing.

Test: layout::tests::a_split_rows_middle_and_bottom_cells_are_lined_up_by_the_text_they_keep. A row of 40 one-line paragraphs beside two cells of twelve three-line paragraphs, pushed down so that 17 lines stay on the first page, in three combinations of top, middle and bottom: the lines kept are 17, 15 and 15, the cells two lines short start one line down in the middle and two at the bottom, also against a centred or bottom-aligned cell's 17 lines, and on the second page every cell goes on at the top. With 30 one-line paragraphs, so that the lined-up cells have the most text left, the paragraph after the table stays where it is without the lining up. Without the change: "top, middle, bottom: cell 1 starts 0 pt below the first on the first page, expected 15.912003"; without the second point alone: "the paragraph after the table is at 391.23996, without the lining up at 407.15198".

The existing tests of split rows pass unchanged, among them a_middle_or_bottom_cell_of_a_split_row_lines_up_on_the_first_page and the two about a space after beside a bottom cell.

Checked:

• cargo fmt --all -- --check
• cargo clippy -p wordcraft-layout --all-targets -- -D warnings
• cargo test -p wordcraft-layout: 715 passed, 3 failed. The three (auto_hyphenation_breaks_long_words, fragmented_hidden_text_lays_out_like_the_visible_text, hyphenation_and_proofing_follow_each_runs_language) fail the same way on main in my container, which has no hyphenation patterns.
• I did not run the other crates' tests or the full cargo xtask ci: the change is inside the layout crate's table code.

Compared with Word's PDFs:

• the file from Tables: a middle or bottom cell of a split row whose text goes on to the next page starts at the top; Word lines it up by the text it keeps #6579 and ten more rows in two files (all three cells aligned, a row over three pages, cells that end on the first or the second page), 1137 marked lines: every one within 0.3 pt of Word's and on Word's page; on main 105 of them are 11.5 or 23 pt high.
• 91 insurance forms filled with made-up data, each word's position compared with Word's PDF. 21 change, the other 70 come out exactly as on main. By the count of words more than 1 pt higher or lower than in Word (23230 before, 23119 after in the 21) 5 are closer and 4 further; the page of every word and the words to the side are unchanged. Together with my other open table fixes and Layout: a hidden end-of-cell mark after a closing line break takes no room #5457 the same change brings 15 forms closer and 7 of them to no difference at all.
• The 4 that get further: their row is cut two lines earlier than in Word (a difference of its own, on main too), so the cells keep other text than in Word and are lined up by that. In one of them the right cell now starts 2.5 pt low where it was in place, and the left one is 7.9 pt high before and after.

After a follow-up (02bc9cb9)

The cells lined up against the most text kept by the cells that run from the top in the part. A cell aligned to the middle or the bottom whose text all stays there was left out of that, so beside one that was the tallest the others stood too high. It counts as text kept now (seven lines in align_in_part).

Measured in Word for Windows 16.0.20625 with lines of 9.2 pt and room for four of them: a top cell that keeps three lines (its fourth and fifth are one paragraph), a cell of four lines that stays whole, a centred cell of two lines, a bottom cell of one line and a centred cell of three. How far the first line of the last three stands below the first line of the top cell, in points:

Test: a_split_rows_cells_line_up_against_an_aligned_cell_that_stays_whole (the three rows of the table; without the change "Some(Center): cell 2 starts 0.49999952 lines down, not 1"). cargo test -p wordcraft-layout --lib: 716 passed, the same 3 hyphenation tests fail as on main in my container; cargo fmt --all -- --check and cargo clippy -p wordcraft-layout --all-targets -- -D warnings are clean.

On our 91 insurance documents, on top of my other open fixes, 8 change with this commit: all 8 get closer to Word and none further, and five of them end up word for word where Word has them (69 of the 91 do, from 64).

After a second follow-up (9d303819)

From the review of #6646, whose code this is. A cell that goes on while it keeps a row of a table was lowered by that row's text alone. A nested row ends below its text, at its bottom border, so its area was pushed across the page's bottom and cut there, a row marked Can't Split too. The areas of the rows of tables that end above the limit now count as what the cell keeps (three lines in align_in_part; the cell's own area needs no telling apart, it runs to the row's bottom, past the limit).

Measured in Word for Windows 16.0.20625: a cell that keeps a nested row with 30 pt of cell margin under its one line of 9.2 pt, while the paragraph of three lines after it goes on, beside a cell of ten lines. Baseline of the nested row's line on the first page:

In Word the nested row's bottom border ends where the text kept beside it does (bottom) or half way there (centred). In the first four rows 02bc9cb9 also cut the nested table at the page's bottom and started the paragraph after it 1.5 to 29.4 pt low on the next page; 9d303819 does neither.

Test: a_cell_that_goes_on_is_lowered_by_the_nested_row_it_keeps_too; without the change a piece of the nested row 28.8 pt tall goes on to the next page. cargo test -p wordcraft-layout --lib: 717 passed, the same 3 hyphenation tests fail; cargo fmt --all -- --check and cargo clippy -p wordcraft-layout --all-targets -- -D warnings are clean.

One overlap comes with it. #6640 moves a row of a table in a cell on whole when the border its table closes with does not fit under it, and such a row can end above the limit. It is not kept, so it must not count here. Whichever of the two is merged second needs those rows left out of this count; I have the two merged locally that way.

On our 91 insurance documents, merged with my other open fixes, this commit moves no word.

Summary by CodeRabbit

• Bug Fixes
  • Improved vertical alignment for middle- and bottom-aligned cells in table rows that span pages. Content remaining on the first page now aligns within that page, while cells start at the top of the continuation page.
  • Preserved the row’s total height and the position of content following a split table.
• Tests
  • Added coverage for alignment across split rows, including text, nested rows, and fully retained cells.
• Documentation
  • Updated the layout behavior reference and checklist for split table rows.